User interfaces allow the computer user to interact or communicate with the computer system. User interfaces are typically implemented with a display screen and a user-controlled entry device, such as a keyboard, mouse, microphone, light pen or the like. The display screen displays information and data to the user and the user uses the entry device to give commands and provide information to the computer system.
During recent years, more and more people have wanted and needed to use the power of the computer in their daily work. However, generally these users do not want to be required to know specific commands, operators, syntax rules, etc, and much work has been expended on developing user interfaces which alleviate the need for such levels of knowledge. The most common form of user interface nowadays is the so-called graphical user interface (or GUI). Typically, a GUI presents the user with windows and icons. Windows typically include a menu bar, a tool bar, and a client area. The client area may typically include a number of icons, which are small stylized representations of entities (applications, folders, etc) with which the user works.
To enable the user to invoke particular operations on the computer system, the user interface needs to provide selection mechanisms to the user. In a typical user interface environment, this may be achieved by defining `actions` which the user can select via `views` of those actions provided via the user interface. For the purposes of this application, an action can be defined as a user initiated event which invokes an operation. The `views` used to represent an action within the user interface may take a number of different forms, both visual and non-visual.
Typical examples of visual views used in GUIs would be a word or phrase on a menu bar (as illustrated in FIG. 1A where the `Print` action is selected from a word view), a graphical representation such as an icon or bitmap on a tool bar (as illustrated in FIG. 1B where the `Print` action is selected from a print bitmap view), or other visual controls that enable user selection or input. Examples of such other controls are a combination box control that allows font selection (as illustrated in FIG. 1C), or an entry field that allows the setting of a string property such as setting the name of a directory or setting a tool bar name (as illustrated in FIG. 1D). Further examples of visual views are illustrated in FIG. 1E, where the print action is selectable from a context or pop up menu displayed by depressing the right mouse button whilst positioned over the window area, and in FIG. 1F where the print action is selectable from a push button view in a window layout.
The present invention concerns visual views of actions (as opposed to non-visual views), and in particular techniques which enable a user to group views together so that, for instance, views of actions most commonly used by the user can be grouped together.
In current day applications, the views for a set of actions are often grouped together in some way. For example, sets of actions may be represented as menu bars, tool bars and pop up menus, as already illustrated in FIGS. 1A, 1B and 1E respectively. For the purposes of the present application, such groupings of views shall be referred to herein as `collective views`. When the application developer is developing the application, he/she will generally create collective views to represent a logical grouping of actions. However, from the end user's point of view, these groupings may not represent the ideal groupings that the user would like.
However, unfortunately, most modern day applications only provide the user with limited ability to customise the collective views defined by the developer. For instance, Lotus Notes provides a `smart icon` facility, whereby the user can control the content of tool bars by using a drag and drop mechanism to drag actions from a list on to a tool bar. The mechanism of dragging and dropping UI objects in GUIs is well known to those skilled in the art, and hence need not be described in any more detail herein. With regards to the list in Lotus Notes, each entry in the list provides the user with a graphical image and a name identifying the action represented by that image. Further Lotus Wordpro extends the smart icons functionality by not only allowing the content of tool bars to be modified by the user but also specifying the context in which a selected tool bar will display.
Microsoft Word allows both customisation of tool bars and menu bars through drag and drop mechanisms. Customisation extends to allowing the user to assign keyboard fast key selections (or accelerators) to actions. The possible list of actions that the user can choose from also includes some actions that have a control type interface such as a combination box (sometimes referred to as a drop down list). An example of this type of action is a font selection action that displays a set of fonts within a drop down list, the user being able to select one of the fonts to change the font of selected textual objects within the client area.
Whilst the above mechanisms provide the user with some ability to customise tool bars, menu bars and keyboard fast key selections (or accelerators), they do not provide mechanisms for customising other types of collective views. Further, they are limited to certain types of actions. In particular, these techniques are not used for all types of actions that appear within the user interface. A category of action which is not generally made available for user selection during customisation is a `property action`. Herein the term `property action` will be used to refer to those actions that hold an item of user-selectable data such as a font name, a file name, etc. The user-selectable data may be chosen by the user from a list of possible data (such property actions may be referred to as `selector` property actions), or alternatively the user may be able to enter the data directly, eg. through an entry field. Although Microsoft Word provides the limited capability of allowing the user to select certain selector property actions from the list of all available actions, it does not allow all of the property actions within its interface to be dragged and dropped on to collective views.
Since property actions have some user-selectable data associated therewith, they tend to be made available to the user via views such as combination box controls or entry fields, such views having already been illustrated with reference to FIGS. 1C and 1D respectively. Since views of property actions include user-selectable data, it is more difficult to provide for such views to be moved around between various collective views, because there is then a requirement to provide some mechanism to handle view concurrency (ie any change to the user-selectable data in one view must be replicated in any other view of that property action). Hence prior art techniques such as the `smart icons` available in Lotus Notes have only enabled such customisation in relation to views of more standard actions such as cut, paste, copy, save, etc which do not include user selectable data. Further, whilst the prior art techniques within Microsoft Word allow a pre-defined number of property actions to be selected by the user and added to the tool bar, this is the exception rather than the norm, and they do not allow all property actions to be moved between different collective views.
It should also be noted that, because property actions are typically represented via rather `large` views such as entry fields and combination box controls, then even if techniques were provided which enabled any number of them to be dropped on to collective views, it is questionable whether collective views such as tool bars would be suitable for holding views of property actions, since at present tool bars tend to be small so that they do not occupy too much of the application display area. A user would soon `outgrow` the tool bar if he/she were to add property action views such as combination box controls and entry fields. Further, the tool bar is also not designed to show larger views such as list boxes or vertically arranged groups of check boxes and buttons.
Another type of collective view which illustrates the customisation problem facing users of GUI applications is the notebook. A typical notebook is illustrated in FIG. 2. As can be seen from that figure, the notebook consists of a number of pages, and any particular page can be accessed by selecting a tab associated with that page. An example of a notebook is the desktop settings notebook provided in the IBM OS/2 operating system. This notebook contains ten or so pages, each of which contains a number of entry fields, combination boxes, buttons, and other views. Additionally, some pages include a number of subsidiary pages. Hence, a notebook is potentially a powerful tool, since it can contain a large number of actions therein. However, up to now, the end user has not been provided with any facility to customise these notebooks, and so, even though the user may only use a small subset of the actions on a regular basis, he/she needs to spend a significant amount of time going through the various pages of often quite large notebooks trying to remember where the particular actions that he/she requires are located.
From the above discussion, it will be apparent that there is a need for a mechanism to be provided which will enable the end user to customise collective views to include those actions which he/she wishes to group together, eg those which he/she makes most use of.